격리된 테스트

각 단위 테스트가 서로 격리되도록 만들기. 테스트 주도 개발 패턴 중 하나. 이상적으로는 문제가 하나이면 실패하는 테스트도 하나여야 한다.

테스트 격리를 얼마나 완벽하게 해야할까

완벽히 지키기보다는 의식적으로 관리할 리스크로 취급하기:

Notice that we have opened ourselves up to a risk. If the test for equality fails to accurately check that equality is working, then the test for multiplication could also fail to accurately check that multiplication is working. This is a risk that we actively manage in TDD. We aren’t striving for perfection. —Chapter 4, Test-driven development: by example

테스트 격리와 고응집 저결합

내가 처음으로 경험한 자동화된 테스트는, 내가 만들던 디버거를 위해 밤새도록 실행되는 GUI 기반 테스트였다. 매일 아침 출근하면 내 의자에는 지난밤 테스트 결과를 담은 종이더미가 놓여 있었다. 운이 좋으면 아무 것도 깨지지 않았음을 알리는 종이 한 장만 있었다. 어떤 날엔 장마다 실패가 하나씩 있는, 정말 많고 많은 종이가 좋여 있기도 했다. 의자에 종이 더미가 쌓여 있는 날이면 악몽 같은 하루가 시작되는 것이다.

이 경험에서 두 가지 교훈을 얻었다. 하나는 테스트가 충분히 빨라서 내가 직접, 자주 실행할 수 있게끔 만들자는 것이다. 그렇게 되면 내가 만든 에러를 다른 누구보다 먼저 내가 잡을 수 있고, 더 이상 악몽 같은 아침도 없을 거다. 두번째 교훈은 어마어마한 양의 종이더미가 반드시 어마어마한 양의 문제를 의미하는 것은 아니라는 점이다. 앞 부분에서 실행된 테스트가 실패한 후 그 영향으로 다음 테스트부터는 시스템이 예측 불가능한 상태에 놓이는 경우가 허다하다. …

주된 교훈은 각각의 테스트는 다른 테스트와 완전히 독립적이어야 한다는 것이다. 즉 문제가 하나면 테스트도 하나만 실패해야 하고, 문제가 둘이면 테스트도 두 개만 실패해야 한다.

격리된 테스트가 암묵적으로 내포하는 특징 중 하나는 테스트가 실행 순서에 독립적이게 된다는 점이다. 테스트의 일부만 실행해보고 싶으면 선행 테스트가 실행되지 않아서 내가 고른 테스트들이 실패하지 않을까 걱정할 필요 없이 그렇게 할 수 있어야 한다. … 격리된 테스트가 내포하는 게 또 하나 있는데, 이는 주어진 문제를 작은 단위로 분리하기 위해 노력해서 각 테스트를 실행하기 위한 환경을 쉽고 빠르게 세팅할 수 있게 해야한다는 것이다. 테스트를 격리하기 위한 작업은 결과적으로 시스템이 응집도는 높고 결합도는 낮은 객체의 모음으로 구성되도록 한다. 나는 이러한 방식으로 시스템을 설계하는 것이 좋다는 말을 항상 들었고, 이런 설계를 얻어냈을땐 기뻐했다. 하지만 일상적으로 격리된 테스트를 하는 습관을 들이기 전까지는 어떻게 하면 이렇게 응집도를 높이고 결합도를 낮출 수 있는지 정확히 이해할 수 없었다.

—p206-207, Test-driven development: by example

Test coupling

Test coupling has an obvious nasty effect, in that breaking one test causes the next ten to fail even though the code is correct. Test coupling can have a subtle but very nasty effect, in situations in which the order of tests matters: If I run test A before test B, they both work, but if I run test B before test A, then test A fails. Or even nastier, the code exercised by test B is wrong, but because test A ran first, the test passes. —Chapter 19, Test-driven development: by example